//
//  main.m
//  Test_Block
//
//  Created by Shreker on 16/7/30.
//  Copyright © 2016年 Shreker. All rights reserved.
//  http://blog.parse.com/learn/engineering/objective-c-blocks-quiz/

#import <Foundation/Foundation.h>

#pragma mark - ExampleA
// Always works. This always works. The stack for exampleA doesn't go away until after the block has finished executing. So whether the block is allocated on the stack or the heap, it will be valid when it is executed.
void exampleA() {
    char a = 'A';
    ^{
        printf("%c\n", a);
    }();
}

#pragma mark - ExampleB
// Only works with ARC. Without ARC, the block is an NSStackBlock allocated on the stack of exampleB_addBlockToArray. By the time it executes in exampleB, the the block is no longer valid, because that stack has been cleared. With ARC, the block is properly allocated on the heap as an autoreleased NSMallocBlock to begin with.
void exampleB_addBlockToArray(NSMutableArray *array) {
    char b = 'B';
    [array addObject:^{
        printf("%c\n", b);
    }];
}
void exampleB() {
    NSMutableArray *array = [NSMutableArray array];
    exampleB_addBlockToArray(array);
    void (^block)() = [array objectAtIndex:0];
    block();
}

#pragma mark - ExampleC
// Always works. Since the block doesn't capture any variables in its closure, it doesn't need any state set up at runtime. it gets compiled as an NSGlobalBlock. It's neither on the stack nor the heap, but part of the code segment, like any C function. This works both with and without ARC.
void exampleC_addBlockToArray(NSMutableArray *array) {
    [array addObject:^{
        printf("C\n");
    }];
}
void exampleC() {
    NSMutableArray *array = [NSMutableArray array];
    exampleC_addBlockToArray(array);
    void (^block)() = [array objectAtIndex:0];
    block();
}

#pragma mark - ExampleD
// Only works with ARC. This is similar to example B. Without ARC, the block would be created on the stack of exampleD_getBlock and then immediately become invalid when that function returns. However, in this case, the error is so obvious that the compiler will fail to compile, with the error error: returning block that lives on the local stack. With ARC, the block is correctly placed on the heap as an autoreleased NSMallocBlock.
//typedef void (^dBlock)();
//dBlock exampleD_getBlock() {
//    char d = 'D';
//    return ^{
//        printf("%c\n", d);
//    };
//}
//void exampleD() {
//    exampleD_getBlock()();
//}

#pragma mark - Example E
// Only works with ARC.????????? This is just like example D, except that the compiler doesn't recognize it as an error, so this code compiles and crashes. Even worse, this particular example happens to work fine if you disable optimizations. So watch out for this working while testing and failing in production. With ARC, the block is correctly placed on the heap as an autoreleased NSMallocBlock.
typedef void (^eBlock)();
eBlock exampleE_getBlock() {
    char e = 'E';
    void (^block)() = ^{
        printf("%c\n", e);
    };
    return block;
}
void exampleE() {
    eBlock block = exampleE_getBlock();
    block();
}

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        exampleE();
    }
    return 0;
}


/*!
 * Conclusions
 
 So, what's the point of all this? The point is always use ARC. With ARC, blocks pretty much always work correctly. If you're not using ARC, you better defensively block = [[block copy] autorelease] any time a block outlives the stack frame where it is declared. That will force it to be copied to the heap as an NSMallocBlock.
 
 Haha! No, of course it's not that simple. According to Apple:
 Blocks "just work" when you pass blocks up the stack in ARC mode, such as in a return. You don't have to call Block Copy any more. You still need to use [^{} copy] when passing "down" the stack into arrayWithObjects: and other methods that do a retain.
 
 But one of the LLVM maintainers later said:
 We consider this to be a compiler bug, and it has been fixed for months in the open-source clang repository. What that means for any hypothetical future Xcode release, I cannot say. 🙂
 So, hopefully Apple was describing a workaround for bugs that existed at the time their guide was written, and everything should work smoothly with ARC and LLVM in the future. But watch out. 😉
 */
